深夜 1 : 15,貝老闆在 Replit Console 狂敲 enter:
貝老闆(電話外放,語速 1.5 倍):「小可,小可!我照 AI 提示把 users 表加 email 欄位,結果原本留言資料都消失啦!😱」
小可(熊貓眼):「老、老闆……你剛剛是不是直接把資料庫砍掉重建?我才剛排版完訂閱頁面耶……」
貝老闆:「我只是跟 AI 說『新增欄位』,它就把整個 DB 重新建啦!資料去哪了?」
(掛電話,立即撥給好威)
好威(啜咖啡):「兄弟,你把改 DB Schema當成改 Excel 嘛?先備份、再 Migration,懂?」
貝老闆:「但 AI 不是會處理嗎?」
好威:「AI 不是你肚子裡的蛔蟲,你沒描述『保留舊資料』它就以為可整碗打掉重練。」😂
好威解析
🔍 概念拆解
1️⃣ Schema Modeling(結構設計)
在正式收集 Email 之前,先畫出 Entity‑Relationship Diagram,釐清 users、subscribers 等實體與欄位。良好的 Schema 可減少重複與未來修改成本。若你只是把 Key 當字串塞入,很快就會被「欄位散落各地」的技術債綁死。實務上建議:
2️⃣ Migration Strategy(演進策略)
當結構需要改動時,正確流程應是:備份 → 撰寫 Migration → 執行 → 驗證 → Commit。舉 Python 常用的 ORM tool Alembic 為例:它會自動產生 upgrade/downgrade 函式;你可叫 AI:「產生一支 Alembic revision,新增 email 欄位且將既有 contact 值搬移過去」。如此 AI 會同時生成 SQL 與資料遷移腳本,而不是砍掉重來。若使用 Replit DB,最少也要:
記住:如果上面的都聽不懂,就先請 AI 講解給你聽!
3️⃣ Prompt‑Driven DB Ops(指令溝通)
AI 助手並非 DBA,它需要上下文。給 AI Prompt 時,務必包含:
💡 Takeaways
精煉重點:
今日提問
你曾因「偷偷改表結構」導致資料消失嗎?分享你的災難瞬間,或留言告訴我們你會如何向 AI 下指令來避免!
Prompt 小作業
試著寫一段 Prompt:
「我要在 Replit DB 中新增 email 欄位,保留所有既有 users 資料並生成可回滾腳本,請用 Python 示範。」
貼到 AI 後觀察它產出的步驟是否含備份與驗證,再留言你的結果!